In the world of Trusted Execution Environments (TEEs), the Trusted User Interface (TUI) has emerged as a technology of interest. The basic idea is that an electronic device, such as a smart phone for example, implements two operational environments or domains: a normal environment and a secure environment. The normal environment runs feature-rich computer operating systems (OSs) and frameworks, such as Windows Mobile, Android, Linux, etc., and the secure environment is separate from the normal environment through hardware such that the normal environment cannot access resources of the secure environment.
Hardware separation can be implemented in a number of ways, e.g., using ARM TrustZone technology, which is a system-wide approach to security on high performance computing platforms for applications, such as secure payment, digital rights management (DRM), and enterprise and web-based services. Information about ARM TrustZone is available on the internet currently at www.arm.com/products/processors/technologies/trustzone.php, among other places.
In a typical device, the rich OS has full control over the device's display screen and input device(s), such as keyboards, touchpads, etc. Nevertheless in some devices, it is useful for the secure environment to control all or part of the user interface (UI), such as a portion of the device's display screen. The idea is that the rich OS should not be able to “spoof” the user input or influence what is shown on the display (or the trusted portion of it) during such a trusted UI session (TUI). A TUI session is usually expected to be brief, for example, just long enough to enter a password or PIN code.
For an example of a useful scenario, assume that the electronic device is running a banking application running in the normal environment, and call the banking application a Client Application (CA). The CA has a corresponding Trusted Application (TA) in the secure environment that serves the CA with specific services. The TA and the user's bank share a secret key, which is encrypted and stored in the electronic device in the secure environment in trusted storage. When the banking CA wants to login to the bank, the CA calls the TA to show a TUI to the user, enabling the user to enter a password, PIN code, or other identification. The entered password is encrypted together with some additional nonce information from the bank using a key shared by the electronic device and the bank, and the encrypted information is sent to the CA, which forwards it to the bank.
The authentication protocol in the above example lacks some features critical for security, but what is important for purposes of this application is that the CA and rich OS must not be able to see or spoof the user input in the secure environment (i.e., the password, in this example).
For another example of a useful scenario, consider a standard web browser and how such a browser is used for secure transactions between a remote server and an electronic device running the browser. How can the user be sure that what is rendered in the browser window is really what the server sent and is not false information arranged to obscure the real information?
Simply put, the problem with the typical TUI is the following: how can a user be sure that the TUI really is displaying the secure environment and that the TA is really handling the user input and display? This is a difficult problem as it is relatively easy for a rogue application running in the normal environment to display a copy of a secure window that calls a user to enter a password or other private information. The user would not know the difference.
Some ideas have been developed to deal with this problem, including having the electronic device include a special indicator, such as an LED, that is hardware controlled by the secure environment and that is illuminated during a TUI session. The drawback is that the special indicator is extra material and that increases the cost of the electronic device, as well as its power consumption.
Another idea is to have the user select an “authentication picture”, e.g., on a server of the device manufacturer. The selected image is sent in an encrypted form to the secure environment in the device and stored, and so the selected image is unknown to the normal environment. Whenever a TUI session is going on, the authentication image is shown in a portion of the TUI, indicating the authenticity of the TUI. A drawback is that is the authentication image does not completely cover the TUI, the normal environment might be able to overlay one or more parts of the TUI with false information, for example to change the displayed amount of a banking transaction from C=1000 to C=100 by covering the last zero. The user would believe the transaction is for C=100 and approve it, but in reality, the transfer would be for C=1000. That drawback can be mitigated if the authentication image covers the whole TUI, but then the image must be significantly dimmed so as not to disturb the information and input fields of the TUI, making it more difficult for a user to recognize that the shown authentication image really is the image the user had chosen.
These ideas are described in the literature. For example, GB 2421093 A by Band for “Trusted User Interface” describes a personalized indicator that is requested from a user, saved in secure storage in a device, and displayed or rendered when trusted system components take control of the device's display. International Publication WO 2008/048800 A1 by Hartrell et al. for “Identification and Visualization of Trusted User Interface Objects” describes a verification rendering engine that re-renders TUI objects in a manner that is based on whether the objects are verified, which is said to improve visual recognition of verified TUI objects over non-verified UI objects.
Nevertheless, known methods and apparatuses for indicating authenticity on a display screen of an electronic device still suffer from the drawbacks described above as well as other drawbacks.